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DETAILED ACTION 
Response to Arguments 

1 . Applicants' arguments filed 07/22/2003 have been fully considered but 
they are not persuasive. 

As argued by applicants: 

Miyachi fails to teach or suggest receiving at a reporting application a request from a client, 
wherein the request includes information specifying a query for a system attribute. 
Miyachi teaches a technique of selecting trigger conditions and fails to suggest that a user can 
form a query. More specifically, Miyachi fails to teach or suggest that a client can submit a 
request to be notified of a condition of an attribute of a system wherein the request comprises 
information specifying a query for the system attribute. For instance, the user in Miyachi does not 
specify a query for a system attribute. Rather, the user may select certain ones of predefined 
trigger conditions that are available for selection, such as those shown in Tables 1 and 2 of 
Miyachi, 

Examiner respectfully traverses because of theses reasons: 
As defined in Microsoft Press Computer Dictionary 3'^ edition, 

Query is a process of extracting data from a database and 
presenting it for use, or a specific set of instructions for 
extracting particular data repetitively. 



As shown in FIG. 4, a technician is allowed to select a number of MFP status 
conditions to monitor in step 420. Next, the program allows the technician to select a 
number of trigger conditions to trigger notification in step 430. For example, the 
technician may select an increment for notification, such as to be notified every time the 
fuser counter reaches another thousand counts. In addition, the technician may select 
as a trigger condition an immediate call back. Such a trigger condition would be useful 
where the technician use the remote monitoring computer 170 through a long distance 
telephone connection, and desires the Host to initiate the call to reduce the technician's 
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costs. The trigger conditions may be reset in step 435 and the processor 230 begins a 
monitoring and notification loop in step 440 (Miyachi, Col. 9, line 40-Col. 10. line 50). As 
seen, a request of notifying of a condition of a system attribute as discussed above 
comprises information specifying the process of extracting system attribute from a 
database, monitoring system for existence of condition of attribute and presenting it to a 
user. This satisfies the query defined by Microsoft Press Computer Dictionary 3^^ edition 
as a specific set of instructions for extracting particular data 
repetitively. In other words, the Miyachi technique indicates the request comprises 
information specifying a query for said system attribute) and using said query for monitoring 
said system for existence of said condition of said attribute. 



As argued by applicants: 

To the extent that a trigger condition is selected in Miyachi, the status information database is 
analyzed for such trigger condition, rather than the system being queried as specified by a 
received request. For instance, Miyachi teaches that, irrespective of a selected trigger condition 
(or any other received request), an MFP collects certain status information, A Host requests the 
collected status information and stores it to a database, and such database may be analyzed to 
determine whether a selected trigger condition is satisfied. Thus, the system is not queried as 
specified by a received request, but rather the MFP collects certain status information 
irrespective of any request that may be received. 



Examiner respectfully traverses because of theses reasons: 
As specified in applicants' specification, pages 23-24: 



// is desirable to bracket multiple such modifications into a single notification unit. Database 
transactions have long been used to bracket multiple database changes into a single atomically 
applied set. For example, suppose a bank database brackets the transfer of funds from a first 
account to a second account as a single atomically applied set. Such bracketing ensures that the 
database will recognize the entire bracketed transaction or none of it. Thus, if the bank's 
computer system crashes in the middle of a transfer, the database will not recognize removal of 
funds from the first account without recognizing the addition of the funds in the second account. 
Rather, the database will either recognize the entire transfer activity or none of it. 
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In a similar manner, the reporting application may use transactions to bracket changes with 
respect to notification requirements. For example, suppose that a disk is moved within a system 
firom a first logical construct to a second logical construct, A client may only want to be notified 
of the disk being moved, rather than being notified that the disk was removed and then being 
notified that it was added. 



As seen, a database is used to record the system status for notification 
requirements. Therefore, the Miyachi technique as discussed above indicates the 
request comprises information specifying a query for said system attribute. 



As argued by applicants: 

The motivation to modify Miyachi in the manner proposed by the Examiner is improper, as the 
motivation must be described in a prior art reference and must detail the benefits of such a 
modification. As such, the proposed modification of Miyachi is improper, and therefore, the 
rejected claims are not obvious under 35 U.S.C, § 103(a), 

Examiner respectfully traverses because a request for notifying of a condition of 
a system attribute as discussed above comprises information specifying the process of 
extracting system attribute from a database, monitoring system for existence of 
condition of attribute and presenting it to a user. This satisfies the query defined by 
Microsoft Press Computer Dictionary 3^^ edition as a specific set of 
instructions for extracting particular data repetitively. \n other 
words, the Miyachi technique indicates the request comprises information specifying a 
query for said system attribute. 

Thus, it is believed that claims 1,13 and 18 are not defined over the Miyachi prior 
art. In addition, claims 2-12, 14, 16-17 and 20-22 depend directly or indirectly upon 
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claims 1,13 and 18 are also rejected as being unpatentable over Miyachi in view of 
Onaga and SQL User's Guide as discussed in the office action. 

Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 103(a) which fornis the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

This application currently names joint inventors. In considering patentability of 

the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 

the various claims was commonly owned at the time any inventions covered therein 

were made absent any evidence to the contrary. Applicant is advised of the obligation 

under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 

not commonly owned at the time a later invention was made in order for the examiner to 

consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e). (f) or (g) 

prior art under 35 U.S.C. 1 03(a). 

3. Claims 1-4, 8-10, 13, 16-18 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Miyachi [USP 6,108,492]. 

Regarding to claim 1 , Miyachi teaches a method for providing notification of a 
technician remote from a machine of the need for machine assistance (Miyachi, Col. 3, 
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lines 43-57). As shown in FIG. 1 is a LAN 100 includes a file server 120, workstations 
150, printers 180 and a Host 1 10b coupled to one another via network communications 
lines 160 (Miyachi, Col. 4. line 38-Col. 5, line 8). As shown in FIG. 2 is a data 
processing system comprising the MFP 110a (multifunction peripheral), and the Host 
1 10b. The MFP 1 10a includes a non-volatile rewritable data storage device 245 for 
storage of various information, include information regarding the status of operation of 
the MFP 1 10a. The Host 1 10b is responsible for periodically initiating a refresh of a 
status information database, which is obtained from the MFP 1 10a and stored in the 
non-volatile rewritable data storage device 240. (Miyachi, Col. 5, line 9-Col. 8, line 67). 
As shown in FIG. 4 is a process for retrieving status information of a MFP. After the 
program has been loaded in step 410, the program allows a technician to select a 
number of MFP status conditions as shown in Tables 1-2, or the entire database to 
monitor in step 420. In step 425-430, the technician is allowed to designate a 
notification method and select a number of trigger conditions. Status information is 
retrieved, and the Host's MFP status database is updated at steps 440-445. If the 
process is to continue, then the processor 230 analyzes the status information database 
in step 455. and determines if any of the trigger conditions have been met in step 460 
(Miyachi. Col. 9, line 35-Col. 10, line 57). Thus, the processor 230 receives a trigger 
condition from a technician as a request for notifying the client the condition of an 
attribute of MFP, and the technique as discussed indicates the steps of receiving a 
request from a client to notify said client of a condition of an attribute of a system; deriving 
data about said system attribute to determine if said condition exists. Miyachi further 
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discloses the step of upon determining that said condition exists^ notifying the client of the 
existence of said condition by initiating a notification in step 465 as indicated in the 
settings received in step 425 (Miyachi, Col. 10, lines 58-65). Miyachi does not explicitly 
teaches the request comprises information specifying a query for said system attribute, and 
using said query for monitoring said system for existence of said condition of said attribute. 
However, as shown in FIG. 4, a technician is allowed to select a number of MFP status 
conditions to monitor in step 420. Preferably, the technician may be notified of any of 
the status conditions in Table 1 and Table 2 of Cols. 6-8, and there is an option to 
provide the entire database. In step 425 the technician is allowed to designate a 
notification method. This preferably comprises designating the telephone number of the 
remote monitoring computer 170, but might also include designating a workstation 150 
on the LAN 100 to be notified. Next, the program allows the technician to select a 
number of trigger conditions to trigger notification in step 430. The technician preferably 
may select particular values at which a trigger condition is to be met. For example, the 
technician might want to be notified when the fuser counter reaches a particular value. 
Preferably, the technician may select an increment for notification, such as to be notified 
every time the fuser counter reaches another thousand counts. In addition, the 
technician may select as a trigger condition an immediate call back. Such a trigger 
condition would be useful where the technician use the remote monitoring computer 170 
through a long distance telephone connection, and desires the Host to initiate the call to 
reduce the technician's costs. The trigger conditions may be reset in step 435 and the 
processor 230 begins a monitoring and notification loop in step 440 (Miyachi, Col. 9, line 
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40-Col. 10, line 50). Thus, a request of notifying of a cx)ndition of a system attribute as 
discussed above comprises information specifying the process of extracting system 
attribute from a database, monitoring system for existence of condition of attribute and 
presenting it to a user. In other words, the Miyachi technique indicates the request 
comprises information specifying a query for said system attribute', and using said query for 
monitoring said system for existence of said condition of said attribute. Therefore, it would 
have been obvious for one of ordinary skill in the art at the time the invention was made 
to modify the Miyachi method by using query for monitoring condition of system 
attributes in order to maintain and repair electronic devices in a network. 

Regarding to claim 13, Miyachi teaches a computer product for providing 
notification of a technician remote from a machine of the need for machine assistance 
(Miyachi, Col. 3, lines 43-57). As shown in FIG. 1 is a LAN 100 includes a file server 
120. workstations 150, printers 180 and a Host 1 10b coupled to one another via 
network communications lines 160 (Miyachi, Col. 4, line 38-Col. 5, line 8). As shown in 
FIG. 2 is a data processing system comprising the MFP 110a (multifunction peripheral), 
and the Host 1 10b. The MFP 1 10a includes a non-volatile rewritable data storage 
device 245 for storage of various information, include information regarding the status of 
operation of the MFP 110a. The Host 110b is responsible for periodically initiating a 
refresh of a status information database, which is obtained from the MFP 1 10a and 
stored in the non-volatile rewritable data storage device 240. (Miyachi, Col. 5, line 9-Col. 
8, line 67). As shown in FIG. 4 is a process for retrieving status information of a MFP. 
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After the program has been loaded in step 410. the program allows a technician to 
select a number of MFP status conditions as shown in Tables 1-2, or the entire 
database to monitor in step 420. In step 425-430, the technician is allowed to designate 
a notification method and select a number of trigger conditions. Status information is 
retrieved, and the Host's MFP status database is updated at steps 440-445. If the 
process is to continue, then the processor 230 analyzes the status information database 
in step 455, and determines if any of the trigger conditions have been met in step 460 
(Miyachi, Col. 9, line 35-Col. 10, line 57). Thus, the processor 230 receives a trigger 
condition from a technician as a request for notifying the client the condition of an 
attribute of MFP, and the technique as discussed indicates the steps of receiving from a 
client a request to notify said client of a condition of an attribute of a system; deriving data 
about said system attribute; determining from said derived data if said condition exists, 
Miyachi further discloses the step of upon determining that said condition exists, notifies 
said client of the existence of said condition by initiating a notification in step 465 as 
indicated in the settings received in step 425 (Miyachi, Col. 10, lines 58-65). Miyachi 
does not explicitly disclose the request comprises information specifying a query for said 
system attribute; and the step of querying said system as specified by said request. However, 
as shown in FIG. 4, a technician is allowed to select a number of MFP status conditions 
to monitor in step 420. Preferably, the technician may be notified of any of the status 
conditions in Table 1 and Table 2 of Cols. 6-8. and there is an option to provide the 
entire database. In step 425 the technician is allowed to designate a notification 
method. This preferably comprises designating the telephone number of the remote 
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monitoring computer 170. but might also include designating a workstation 150 on the 
LAN 100 to be notified. Next, the program allows the technician to select a number of 
trigger conditions to trigger notification in step 430. The technician preferably may select 
particular values at which a trigger condition is to be met. For example, the technician 
might want to be notified when the fuser counter reaches a particular value. Preferably, 
the technician may select an increment for notification, such as to be notified every time 
the fuser counter reaches another thousand counts. In addition, the technician may 
select as a trigger condition an immediate call back. Such a trigger condition would be 
useful where the technician use the remote monitoring computer 170 through a long 
distance telephone connection, and desires the Host to initiate the call to reduce the 
technician's costs. The trigger conditions may be reset in step 435 and the processor 
230 begins a monitoring and notification loop in step 440 (Miyachi, Col. 9, line 40-Col. 
10. line 50). Thus, a request of notifying of a condition of a system attribute as 
discussed above comprises information specifying the process of extracting system 
attribute from a database, monitoring system for existence of condition of attribute and 
presenting it to a user. In other words, the Miyachi technique indicates the request 
comprises information specifying a query for said system attribute; and the step of querying 
said system as specified by said request. Therefore, it would have been obvious for one of 
ordinary skill in the art at the time the invention was made to modify the Miyachi method 
by using query for monitoring condition of system attributes in order to maintain and 
repair electronic devices in a network. 
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Regarding to claim 18, Miyachi teaches a system for providing notification of a 
technician remote from a machine of the need for machine assistance (Miyachi, Col. 3, 
lines 43-57). As shown in FIG. 1 is a LAN 100 includes a file server 120, workstations 
150, printers 180 and a Host 1 10b coupled to one another via network communications 
lines 160 (Miyachi. Col. 4, line 38-Col. 5, line 8). As shown in FIG. 2 is a data 
processing system comprising the MFP 110a (multifunction peripheral), and the Host 
1 10b. The MFP 1 10a includes a non-volatile rewritable data storage device 245 for 
storage of various information, include information regarding the status of operation of 
the MFP 1 10a. The Host 1 10b is responsible for periodically initiating a refresh of a 
status information database, which is obtained from the MFP 110a and stored in the 
non-volatile rewritable data storage device 240. (Miyachi, Col. 5, line 9-Col. 8, line 67). 
As shown in FIG. 4 is a process for retrieving status information of a MFP. After the 
program has been loaded in step 410, the program allows a technician to select a 
number of MFP status conditions as shown in Tables 1-2, or the entire database to 
monitor in step 420. In step 425-430, the technician is allowed to designate a 
notification method and select a number of trigger conditions. Status information is 
retrieved, and the Host's MFP status database is updated at steps 440-445. If the 
process is to continue, then the processor 230 analyzes the status information database 
in step 455, and determines if any of the trigger conditions have been met in step 460 
(Miyachi, Col. 9, line 35-Col. 10, line 57). Thus, the processor 230 receives a trigger 
condition from a technician as a request for notifying the client the condition of an 
attribute of MFP, and the technique as discussed indicates: means for storing a reporting 
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application; a means for executing said reporting application; wherein reporting application 
includes computer executable software code for receiving from a client a request to notify 
said client application program of a condition of an attribute of a system; determining if said 
condition exists, Miyachi further discloses the step of upon determining that said condition 
exists, notifies said client of the existence of said condition by initiating a notification in step 
465 as indicated in the settings received in step 425 (Miyachi. Col. 10, lines 58-65). 
Miyachi does not explicitly disclose the request comprises information specifying a query 
for said system attribute. However, as shown in FIG. 4, a technician is allowed to select a 
number of MFP status conditions to monitor in step 420. Preferably, the technician may 
be notified of any of the status conditions in Table 1 and Table 2 of Cols. 6-8, and there 
is an option to provide the entire database. In step 425 the technician is allowed to 
designate a notification method. This preferably comprises designating the telephone 
number of the remote monitoring computer 170, but might also include designating a 
workstation 150 on the LAN 100 to be notified. Next, the program allows the technician 
to select a number of trigger conditions to trigger notification in step 430. The technician 
preferably may select particular values at which a trigger condition is to be met. For 
example, the technician might want to be notified when the fuser counter reaches a 
particular value. Preferably, the technician may select an increment for notification, such 
as to be notified every time the fuser counter reaches another thousand counts. In 
addition, the technician may select as a trigger condition an immediate call back. Such a 
trigger condition would be useful where the technician use the remote monitoring 
computer 170 through a long distance telephone connection, and desires the Host to 



Application/Control Number: 09/422,998 Page 13 

Art Unit: 2172 

initiate the call to reduce the technician's costs. The trigger conditions may be reset in 
step 435 and the processor 230 begins a monitoring and notification loop in step 440 
(Miyachi, Col. 9, line 40-Col. 10, line 50). Thus, a request of notifying of a condition of a 
system attribute as discussed above comprises information specifying the process of 
extracting system attribute from a database, monitoring system for existence of 
condition of attribute and presenting it to a user. In other words, the Miyachi technique 
indicates the request comprises information specifying a query for said system attribute. 
Therefore, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to modify the Miyachi method by using query for monitoring 
condition of system attributes in order to maintain and repair electronic devices in a 
network. 

Regarding to claim 2, Miyachi teaches all the claimed subject matters as 
discussed in claim 1 but fails to disclose the step of generating derived data based upon 
the result of said query of said system. However, according to Miyachi, the client may be 
notified of any of the status conditions or the entire database after the step of status 
condition selection (Miyachi, Col. 9, lines 39-46), this implies the step of generating 
derived data based on the result of selection step. Therefore, it would have been 
obvious for one of ordinary skill in the art at the time the invention was made to include 
the step of generating data based on the result of querying in order to display the result 
in a predefined format. 
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Regarding to claims 3 and 16, Miyachi teaches all the claimed subject matters as 
discussed in claims 1,13, Miyachi further discloses: condition is a change in said attribute 
(Miyachi, Col. 9, lines 55-65). 

Regarding to claim 4, Miyachi teaches all the claimed subject matters as 
discussed in claim 1 . Miyachi further discloses: the attribute is selected from the group of 
status of peripheral device, access to local peripherals (Miyachi, Col. 5, line 57-Col. 8, line 
60). Miyachi and Sybase fails to disclose the attribute is selected from the group of: 
membership of nodes within a cluster, configuration of a cluster, failure of computer 
hardware, addition of shared peripherals, removal of shared peripherals, ownership of a 
shared peripheral, availability of shared peripherals for addition to a cluster, resilience to 
faults of a High Availability cluster, performance potential of a cluster, and any combination 
thereof However, Miyachi discloses the background of the invention as a local area 
network (LAN), which linked one or more peripheral devices such as printers, facsimile 
machines, scanners or plotters and typically, the status of a device (Miyachi, Col. 9, 
lines 10-24). Thus, the Miyachi status tables as in col. 6-8 can be modified to have the 
condition state of a node if a user wants to know the condition of a node within a cluster 
or the configuration of a cluster and even the condition to indicate the failure of 
computer hardware, addition of shared peripherals, removal of shared peripheral, 
ownership of a shared peripheral, availability of shared peripherals for addition to a 
cluster, resilience to faults of a High Availability cluster, performance potential of a 
cluster. Therefore, it would have been obvious for one of ordinary skill in the art at the 
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time the invention was made to modify tfie Miyachi status table in order to query tine 
condition of a network's device especially the condition about the status of a node within 
a cluster when a new node is added or deleted from the system. 

Regarding to claim 8, Miyachi teaches all the claimed subject matters as 
discussed in claim 1 , Miyachi fails to teach: information specifying a query for said system 
attribute comprises multiple transactions bracketed together (Col. 9, line 55-Col. 10, line 

21). 

Regarding to claims 9 and 17, Miyachi teaches all the claimed subject matters as 
discussed in claims 1, and 13, Miyachi further discloses: multiple transactions bracketed 
together^ wherein upon determining that such bracketed condition exist, notifying said client 
of the existence of such bracketed conditions (Col. 9, line 55-Col. 10, line 12). 

Regarding to claim 10, Miyachi and Sybase teach all the claimed subject matters 
as discussed in claim 9, Miyachi further discloses the multiple changes are bracketed 
together, wherein upon determining that such bracketed changes exist, notifying said client of 
the existence of such bracketed changes (Col. 9, line 55-Col. 10, line 12). 

4. Claims 5 and 11 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Miyachi [USP 6,108,492] in view of Onaga [USP 6,266,693 B1]. 
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Regarding to claim 5, Miyachi teaches all the claimed subject matters as 
discussed in claim 1 , but fails to disclose: client is selected from the group consisting of a 
user and a client application program, Onaga teaches a method for monitoring status of 
multifunction peripherals (Onaga, Col. 1, lines 25-30). Onaga further discloses four 
classes of users and each of these classes is given access to different classes of 
peripheral settings and features or client is selected from the group consisting of a user and 
a client application program. Therefore, it would have been obvious for one of ordinary 
skill in the art at the time the invention was made to include the step of selection of 
client from the group of a user and a client application program into the Miyachi method 
in order to control the access of client. 

Regarding to claim 1 1 , Miyachi teaches all the claimed subject matters as 
discussed in claim 1 , but fails to disclose: client is a graphical user interface (GUI) that 
displays information to a human user. Onaga teaches a method for monitoring status of 
multifunction peripherals (Onaga, Col. 1, lines 25-30). Onaga further discloses client is a 
graphical user interface (GUI) that displays information to a human user (Onaga, FIG. 9). 
Therefore, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to modify the Miyachi method to have a graphical user interface in 
other to display information to a user. 
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5. Claims 6-7, 14, and 20-22 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Miyachi [USP 6,108,492] in view of Sybase [Transact-SQL 
User's Guide, Copyright 1996]. 

Regarding to claims 6 and 14, Miyachi teaches all the claimed subject matters as 
discussed in claims 1 , and 13, and further disclose the status information are stored in a 
database and a client may select some or all of the information for a predefined trigger 
condition (Miyachi, Col. 3, line 60-Col. 4, line 5; Fig. 4, Col. 9, lines 34-47). Miyachi fails 
to teach information specifying a query for said system attribute is an SQL query. Sybase 
teaches SQL as a high-level language includes commands for retrieving data from a 
database, creating database object and other functions (Sybase, Chapter 1: 
Introduction, Overview). As shown in Chapter 1 is the method of creating SQL 
statements by using select command. As shown in Chapter 14 is the method of creating 
trigger conditions by using SQL statements. Therefore, it would have been obvious for 
one of ordinary skill in the art at the time the invention was made to modify the Miyachi 
method by including the technique of defining a trigger condition by using SQL query as 
taught by Sybase, and by including the Sybase technique, a user-friendly system could 
be provided to the user by defining a trigger condition via either a SQL query or a pre- 
defined query. 
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Regarding to claim 7, Miyachi and Sybase teach all the claimed subject matters 
as discussed in claims 6, Sybase further discloses: SQL query comprises an SQL view 
(Sybase, Chapter 8, Views: Limiting access to Data, Creating Views). 

Regarding to claim 20, Miyachi and Sybase teaches all the claimed subject 
matters as discussed in claim 18, Sybase further discloses the system comprises: 
multiple nodes, wherein at least one of said nodes is executing said reporting application 
(Miyachi, Fig. 1-2, Col. 4-5). 

Regarding to claim 21, Miyachi and Sybase teaches all the claimed subject 
matters as discussed in claim 13, Miyachi further discloses the step oi periodically 
querying the system (Miyachi, Col. 10, lines 14-21). 

Regarding to claim 22, Miyachi and Sybase teaches all the claimed subject 
matters as discussed in claim 1 8, Miyachi further discloses the step of monitoring system 
to determine if said condition cxr/sr (Miyachi, Col. 5, lines 57-65). 

6. Claim 12 is rejected under 35 U.S.C. 103(a) as being unpatentable 
over Miyachi [USP 6,108,492] in view of Onaga [USP 6,266,693 B1] and Sybase 
[Transact-SQL User's Guide, Copyright 1996]. 

Regarding to claim 12, Miyachi and Onaga teaches all the claimed subject 
matters as discussed in claim 1 1 , but fails to teach the step of deriving data to determine 
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if a condition of said one or more attributes exists such that the GUI should redraw the 
graphics displaying said information about said one or more attributes. Sybase teaches 
retrieving data through views by using SQL. the SQL server checks to make sure that 
all the database objects exist and create a view that includes all the attributes as 
indicate in the condition of the query (see Chapter 8, Views. Limiting Access to Data. 
What are Views?, Retrieving Data through Views). Thus, the Miyachi, and Onaga 
method can use SQL to implement the step of condition determination and graphic 
redrawing to make sure the attributes exist and provide a view for these attributes. 
Therefore, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to modify the Miyachiand Onaga method by applying SQL to 
implement the steps of condition determination and graphic redrawing to determine if a 
condition of one or more attributes exists such that GUI could redraw the graphic 
displaying. 

Conclusion 

7. THIS ACTION IS MADE FINAL, Applicant is reminded of the extension of 
time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
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extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

8. Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to HUNG Q PHAM whose telephone number Is 703- 
605-4242. The examiner can normally be reached on Monday-Friday. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, KIM Y VU can be reached on 703-305-4393. The fax phone number for the 
organization where this application or proceeding is assigned is (703) 872-9306. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is 703-305- 
3900. 



Hung Pham 
September 15, 2003 
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